Служба синхронизации времени

Служба синхронизации времени в домене необходима для корректной работы следующих механизмов:

  • аутентификации по протоколу Kerberos;

  • двухфакторной аутентификации на основе синхронизированных по времени одноразовых паролей;

  • разрешения конфликтов при репликации;

  • возможности сопоставления журналов событий с разных серверов.

Служба chrony (демон chronyd) запускается после загрузки операционной системы и начинает отправлять запросы на NTP-серверы, перечисленные в файле конфигурации /etc/chrony/chrony.conf. После получения ответа от NTP-сервера, chronyd обновляет системное время. Процесс синхронизации времени с сервером продолжается на протяжении всего времени работы службы chrony на этих компьютерах. Служба синхронизации времени автоматически определяет оптимальную частоту запросов, обычно делая их каждые несколько минут. Это минимизирует ошибки времени и обеспечивает точность работы системных часов, приближенную к реальной.

Выбор источника точного времени (в реализации «коробочной» групповой политики) в домене для каждого компьютера осуществляется на основе иерархической системы:

# КД - контроллер домена

Внешний источник (или другой эталон)
# это сервер, который находится за пределами инфраструктуры компании

    Корневой КД сайта
    # это контроллеры домена, которые объявлены корневыми через портал управления ALD Pro и которые непосредственно синхронизируются с внешним NTP-сервером

        Обычный КД сайта
        # это контроллер домена, который синхронизирует время с корневым NTP-сервером и дополнительно выступает в качестве источника времени для клиентов из того же сайта

            Корневой КД домена (не из сайта)
            # это контроллер домена, который объявлен корневым через портал управления ALD Pro, но находится в другом сайте относительно клиента NTP

                Обычный КД домена (не из сайта)
                # это контроллер домена, который синхронизирует время с корневым NTP-сервером, но при этом находится в другом сайте

Уровень внешнего источника используется только для корневых контроллеров домена (КД). Если КД на каком-то уровне нет, то берется следующий за ним уровень и осуществляется попытка синхронизации с КД этого уровня.

При установке первый КД автоматически становится корневым NTP-сервером домена. Дальнейшие изменения конфигурации администратор делает самостоятельно.

На всех корневых КД должна быть следующая конфигурация службы chrony (после применения групповой политики - timeGP):

{{allow 0/0       }}
{{stratumweight 1 }}
{{combinelimit 0  }}
{{local stratum 11 orphan     }}
server some_external_ntp_server iburst minstratum 11        # при наличии записи (записей) в ПУ

На всех КД, которые не являются корневыми, должна быть следующая конфигурация службы chrony (после применения групповой политики - timeGP):

{{allow 0/0       }}
{{stratumweight 1 }}
{{combinelimit 0  }}
{{local stratum 11    }}
{{pool _ntp._udp._roots.{dc_component} iburst minstratum 12 }}
{{pool _ntp._udp._roots._default.{dc_component} iburst minstratum 14 }}

Форсировать обновление настроек /etc/chrony/chrony.conf можно командой:

aldpro-salt-call state.apply policies.host-policies.rbta_ldap_date_time_h

Функционирование подсистемы NTP осуществляется с помощью динамических DNS-записей и групповой политики для синхронизации времени. Дополнительные настройки конфигурационного файла chrony не требуются, т.к. они выполняются в ходе работы групповой политики времени.

Динамические DNS-записи

Начиная с 2.5.0, реализован функционал подсистемы NTP, который выполняет корректировку DNS-записей в базе данных:

  • при добавлении и удалении контроллеров в домен;

  • при изменении привязки контроллеров к сайтам;

  • при изменении параметров корневых NTP-серверов (добавлении и удалении их через портал управления).

Поддерживает выполнение следующих действий:

  • Добавление двух динамических записей типа CNAME для корневых и простых контроллеров в рамках сайтов (locations):

    • _ntp._udp._roots.ald.company.lan ведет на _ntp._udp._roots.{this_location}._locations.ald.company.lan, где:

      {this_location} - конкретный location того DNS-сервера, который обрабатывает запрос;

    • _ntp._udp.ald.company.lan ведет на _ntp._udp.{this_location}._locations.ald.company.lan.

  • Создание двух множеств DNS-записей типа A в рамках сайта (location):

    • _ntp._udp._roots.{some_location}._locations.ald.company.lan - пул A-записей с корневыми NTP-серверами в текущей локации;

    • _ntp._udp.{some_location}._locations.ald.company.lan - пул обычных контроллеров домена в текущей локации (может включать все контроллеры домена, если все КД находятся в одном location).

  • Создание двух множеств DNS-записей типа А в рамках домена:

    • _ntp._udp._roots._default.ald.company.lan - пул всех корневых NTP-серверов домена (CNAME), в том числе и тех, у которых признак location не заполнен;

    • _ntp._udp._default.ald.company.lan - пул контроллеров домена (не CNAME), в том числе и тех, у которых признак location не заполнен.

Алгоритм автоматической настройки подсистемы NTP

Начиная с версии 2.5.0, на КД устанавливается служба aldpro-ntp-management, которая раз в 2 минуты запускает проверку healthcheck NTP. Демон NTP получает данные из LDAP-каталога о записях сайтов, о внешних и корневых NTP-серверах домена, данные всех активных КД (по умолчанию в конфигурационном файле chrony прописана строка «allow 0/0», что позволяем им выступать в качестве NTP-сервера) и данные о DNS-записях. Демон проводит расчет того, как должны выглядеть dns-записи, исходя из всех полученных из LDAP-каталога данных, и сверяет это рассчитанное состояние с тем, которое хранится в каталоге. Если все совпадает, то никаких изменений демон не производит, после чего демон засыпает на 2 минуты, затем процедура повторяется.

Внимание

Демон NTP aldpro-ntp-management устанавливается на каждый КД из состава домена, при этом должен функционировать (находиться в статусе active(running)) только на одном КД домена. Для проверки необходимо на каждом КД выполнить команду:

systemctl is-active aldpro-ntp-management

На всех КД, кроме одного, этот демон должен иметь состояние inactive.

Все запросы к LDAP-каталогу этот демон делает под системной учетной записью uid=saltstackservice,cn=sysaccounts,cn=etc,dc=ald,dc=company,dc=lan.

Все действия демона записываются в журнал службы journalctl, который можно просмотреть командой:

journalctl -u aldpro-ntp-management # для просмотра полного лога службы
journalctl -fu aldpro-ntp-management # для потокового просмотра лога службы

При добавлении любого КД в домен, в сайт, в состав которого вошел этот КД, добавляются записи в ветку службы dns по следующим путям:

idnsname=_ntp._udp._default,idnsname={DOMAIN_NAME}.,cn=dns,dc=*  добавляется атрибут aRecord=IP_ADDRESS_DC
idnsname=_ntp._udp.hq._locations,idnsname={DOMAIN_NAME}.,cn=dns,dc=* при добавлении этого КД в сайт hq также добавляется атрибут aRecord=IP_ADDRESS_DC

При добавлении внешнего NTP-сервера с наименованием server1, в ветку LDAP-каталога cn=ntp,cn=services,cn=aldpro,cn=etc,dc* добавляется запись ntpserver=server1 с атрибутами:

externalntpservertype=server # для пула будет значение pool
isexternal=true
ntpserver=server1

В дальнейшем из этой ветки берутся данные при заполнении конфигурации службы chronyd на всех компьютерах домена с помощью групповой политики времени (см. ниже).

При добавлении нового корневого NTP-сервера домена, т.е. при смене статуса КД с «обычного» на «корневой», его запись (aRecord с IP-адресом этого КД) перемещается и располагается между записями в ветке службы DNS:

  1. из записи сайта для «обычных» КД в запись сайта для «корневых» КД по пути idnsname=_ntp._udp._roots.hq._locations,idnsname={DOMAIN_NAME}.,cn=dns,dc=*;

  2. добавляется aRecord=IP-ADDR_DC в запись idnsname=_ntp._udp._roots._default,idnsname={DOMAIN_NAME}.,cn=dns,dc=*.

Помимо этого, в LDAP-каталог в ветку cn=ntp,cn=services,cn=aldpro,cn=etc,dc* добавляется запись ntpserver=FQDN_DC, где FQDN_DC - fqdn добавленного корневого NTP-сервера домена. Эта запись содержит атрибут isexternal=FALSE и атрибут server=FQDN_DC.

При удалении корневого NTP-сервера домена происходит процесс, обратный сценарию добавления нового корневого NTP-сервера.

Групповая политика времени берет данные из службы каталога, и вносит в конфигурацию chrony необходимую информацию как о наборе параметров, так и о пулах по умолчанию:

pool _ntp._udp._roots.ald.company.lan iburst minstratum 12
pool _ntp._udp.ald.company.lan iburst minstratum 13
pool _ntp._udp._roots._default.ald.company.lan iburst minstratum 14
pool _ntp._udp._default.ald.company.lan iburst minstratum 15

Также политика дополнительно добавляет следующие строки только корневых КД:

pool external_ntp_pool iburst minstratum 11  // при наличии в LDAP записей об одном или нескольких внешних NTP-пулах
server external_ntp_server iburst minstratum 11 // при наличии в LDAP записей об одном или нескольких внешних NTP-серверах

заменяя значения external_ntp_pool на значения атрибутов ntpserver тех записей, у которых атрибут externalntpservertype=pool` (количество таких строк будет равно количеству записей) и значения external_ntp_server на значения атрибутов ntpserver тех записей, у которых атрибут externalntpservertype=server по такой же схеме.

При удалении КД из домена нигде не должно оставаться атрибутов aRecord с IP-адресом этого КД.

При удалении внешних NTP-серверов или пулов должно происходить удаление соответствующей записи cn=ntpserver=DELETED_ITEM в ветке cn=ntp,cn=services,cn=aldpro,cn=etc,dc*. И после срабатывания групповой политики времени (в том числе после перезагрузки корневого КД домена) на всех корневых КД домена эти записи с удаленным сервером/пулом должны пропасть из /etc/chrony/chrony.conf.